微服务作为一种流行的服务架构，已经被越来越广泛地使用和演进。熟悉微服务对于构建优秀的服务架构非常重要。
定义
- 单个服务单个进程，相互独立运行。
- 服务间轻量级通信协议，避免总线模式。
- 独立部署，快速部署。
常见框架
- Spring Cloud - Spring
- Dubbo/Dubbox - Alibaba
- istio - Google, IBM, Lyft
服务通信
可选手段
- REST
- RPC
- 异步
RPC解决方案
- GRPC - Google
- istio - Google
- Dubbo/Dubbox - Alibaba
- Thrift - Facebook
- Linkerd - Twitter
HTTP解决方案
- Spring Cloud - Spring
- Imixs-workflow - Microsoft
服务类型
- 必选：网关+注册中心+配置中心+应用*n。
- 可选：路由+限流+服务监控+服务发现+服务熔断+负载均衡+服务跟踪等。
网关
- Zuul 1 vs. Zuul 2 vs. Nginx vs. Spring Cloud Gateway vs. Linkerd。
- 网关 = 路由 + 过滤器。
- 不需其他微服务各自实现过滤功能，也不需其他微服务同时引用公共的过滤服务，即微服务不需再关心权限校验。
- 多了一层转发，且增加了高可用成本。
- 可集成外部负载均衡、权限校验、路由、监控、限流等。
服务发现
服务端模式
调用方每次调用时直接请求注册中心，注册中心再根据LB策略进行调用。调用方不需维护服务发现逻辑及服务注册信息，非常类似于DNS。
- 简单，客户端不维护服务列表。
- 注册中心负载较高。
客户端模式
客户端周期性地从注册中心获取服务列表，再根据调用端本地的LB策略进行调用。
- 客户端需维护服务列表。
- 注册中心故障也能继续调用其它服务。
Eureka
- 客户端模式。
- RESTful API。
- 各微服务启动时向服务端注册自身，并定期调用服务端renew接口更新自身状态。
- 各微服务可主动注销或服务端超时将其注销。
- 服务端多点部署高可用，同步微服务的注册/注销消息。
Consul
- 客户端模式。
- 基于Raft协议，强调一致性。
- 各服务启动时向微服务注册自身，并提供健康检查的方法，由服务端定期健康检查。
负载均衡
- 此处的负载均衡服务指微服务间调用时的负载均衡。
- 传统的LBS通常是独立的硬件或软件，根据负载算法及映射关系进行转发。
- 微服务的LBS为客户端负载均衡，将LBS集成到服务消费者的进程内，由其选择服务提供者。
Ribbon
- 根据负载算法选择注册中心，获取服务列表。
- 根据负载算法从服务列表中选择服务提供者，进行服务间调用。
服务熔断
目标问题
- 调用链上的若干个服务不可用或延迟较高，导致系统资源不释放或释放缓慢，累积后引发雪崩。
- 服务不可用的处理关键：快速返回，避免等待。
熔断机制
- 类似于“保险丝“，某个微服务在某段时间内达到异常（通常是调用超时）次数或比例的阈值时，在一定时间内熔断该服务。
- 通常配备服务降级：服务不可用时，启用Plan B。
Hystrix
- 命令模式。
- 在服务消费方配置并维护。
- 设置一个断路器，若一段时间内的请求失败数/请求总数控制达阈值，则开启断路器。
- 断路器开启后，请求全部禁止通过或Plan B；过一段时间后断路器进入半开状态，此时只允许少量请求通过，若均成功则关闭断路器，否则继续开启。
其他应对策略
隔离机制
- 对各类请求设置不同的线程池或信号量，若某类请求线程池耗尽或信号量超限，则对该类请求直接返回，不再调用后续资源。
限流机制
- 预防措施。
- 对各类请求设置QPS阈值，若某类请求的QPS达阈值，则对该类请求直接返回，不再调用后续资源。